Most login experiences are performed via a secure website, which Identity Providers (IdPs) control rigidly. Because bots are conversational experiences within chat apps, it is typically clunky and awkward for the bots themselves to authenticate a user. Thus, in order to maintain positive user experiences within a chat application, the authentication process should be more streamlined and elegant, while maintaining a secure connection.
When signing into a web application (e.g., Facebook®, Google®), a user is taken through the OAuth 2.0 flow, which is used to perform authentication and authorization in most application types. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account. This typically works well for web browsers, but is cumbersome for bots. OAuth 2.0 was initially built for redirection on the client side, not the server side. Thus, authenticating a bot user requires the user to copy a large string of numbers and characters (i.e., an identification number) that will bridge the bot channel and a third-party server. The current bot authentication protocol is clunky because users are required to copy and paste this large identification number, which significantly decreases the user experience and increases network traffic.
It is with respect to these and other general considerations that example aspects, systems, and methods have been described. Also, although relatively specific problems have been discussed, it should be understood that the examples should not be limited to solving the specific problems identified in the background.